home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / ietf / urn / urn-archives / urn-ietf.archive.9701 / 000045_owner-urn-ietf _Fri Jan 31 12:31:23 1997.msg < prev    next >
Internet Message Format  |  1997-02-19  |  2KB
  1. Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id MAA03702 for urn-ietf-out; Fri, 31 Jan 1997 12:31:23 -0500
  2. Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id MAA03697 for <urn-ietf@services.bunyip.com>; Fri, 31 Jan 1997 12:31:21 -0500
  3. Received: from windrose.omaha.ne.us by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b)
  4.         id AA26337  (mail destined for urn-ietf@services.bunyip.com); Fri, 31 Jan 97 12:31:16 -0500
  5. Received: by privateer.windrose.omaha.ne.us; Fri Jan 31 11:30 CST 1997
  6. Message-Id: <32F21E1E.4387@ds.internic.net>
  7. Date: Fri, 31 Jan 1997 11:30:22 -0500
  8. From: Ryan Moats <jayhawk@ds.internic.net>
  9. Organization: InterNIC Directory and Database Services
  10. X-Mailer: Mozilla 2.02E (OS/2; I)
  11. Mime-Version: 1.0
  12. To: Daniel LaLiberte <liberte@ncsa.uiuc.edu>
  13. Cc: "Ron Daniel Jr." <rdaniel@lanl.gov>, omar syed <osyed@lerc.nasa.gov>,
  14.         URL mailing list <ietf-url@imc.org>, urn-ietf@bunyip.com
  15. Subject: Re: [URN] Re: Relative URLs and URNs
  16. References: <199701310644.XAA03311@acl.lanl.gov> <199701311656.KAA03953@void.ncsa.uiuc.edu>
  17. Content-Type: text/plain; charset=us-ascii
  18. Content-Transfer-Encoding: 7bit
  19. Sender: owner-urn-ietf@services.bunyip.com
  20. Precedence: bulk
  21. Reply-To: Ryan Moats <jayhawk@ds.internic.net>
  22. Errors-To: owner-urn-ietf@bunyip.com
  23.  
  24. Daniel LaLiberte wrote:
  25. > 
  26. >  > Thus spoke Omar Syed:
  27. >  > > 2. clients must treat <NSS> as an opaque string (i.e. do not interperet)
  28. >  >
  29. > Ron Daniel, Jr. writes:
  30. >  > I think assumption 2 is in error. Clients that know the structure of
  31. >  > a name in a particular namespace are likely to manipulate it.
  32. > 
  33. > I agree.  Clients, of course, can do whatever they want (whatever they
  34. > can get away with) anyway, but they have to be able to interpret the
  35. > structure of an identifier in order to do as much processing of it on
  36. > their own as they can.  Forcing clients (if that were possible) to
  37. > always consult a remote server to process the whole identifier is a
  38. > sure way to make the system unscalable.
  39.  
  40. Just to make everyting clear, if the client does not understand the
  41. namespace, should treat the NSS as an opaque string, yes? (At least,
  42. I certainly hope so...)
  43.  
  44. Ryan